-
-
Notifications
You must be signed in to change notification settings - Fork 4.6k
feat(code_review): Forward pull_request events to Seer #105740
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
| WEBHOOK_EVENT_PROCESSORS = (_handle_pr_webhook_for_autofix_processor,) | ||
| WEBHOOK_EVENT_PROCESSORS = ( | ||
| _handle_pr_webhook_for_autofix_processor, | ||
| code_review_handle_webhook_event, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adding this to the PullRequestEventWebhook class which handles pull_request events.
sentry/src/sentry/integrations/github/webhook.py
Line 1041 in 67db771
| GithubWebhookType.PULL_REQUEST: PullRequestEventWebhook, |
| PULL_REQUEST = "pull_request" |
| sample_rate=1.0, | ||
| tags={ | ||
| "organization_id": organization.id, | ||
| "repository_id": repo.id, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you run the tests with verbosity, you can see that these calls to metrics.incr are failing because these two keys are forbidden due to high cardinality.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ajay-sentry @srest2021 heads up ^ in case you were still using that metric to track billing related stuff for GA
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for catching this!!
| - Sending webhook events with proper authentication | ||
| """ | ||
|
|
||
| OPTIONS_TO_SET: Mapping[str, Any] = {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
suejung-sentry
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is great and much simpler than I expected it to be! Nice!
|
|
||
| EVENT_TYPE = IntegrationWebhookEventType.MERGE_REQUEST | ||
| WEBHOOK_EVENT_PROCESSORS = (_handle_pr_webhook_for_autofix_processor,) | ||
| WEBHOOK_EVENT_PROCESSORS = ( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just for my own mental model, these 2 processors run serially right?
| for processor in self.WEBHOOK_EVENT_PROCESSORS: |
With a failure in 1 does not block the next, and each processor runs synchronous for most of its logic except for the call to seer in
schedule_task which is async?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is correct.
Once the code review processors executes, the work is in the task broker queue and will be handled async.
| sample_rate=1.0, | ||
| tags={ | ||
| "organization_id": organization.id, | ||
| "repository_id": repo.id, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ajay-sentry @srest2021 heads up ^ in case you were still using that metric to track billing related stuff for GA
| def _get_trigger_for_action(action: PullRequestAction) -> CodeReviewTrigger: | ||
| if action == PullRequestAction.READY_FOR_REVIEW: | ||
| return CodeReviewTrigger.ON_READY_FOR_REVIEW | ||
| return CodeReviewTrigger.ON_NEW_COMMIT |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
technically this could be something like below so it's not a burden of the caller of the helper to know which actions are actually valid
match action:
case PullRequestAction.READY_FOR_REVIEW:
return CodeReviewTrigger.ON_READY_FOR_REVIEW
case PullRequestAction.SYNCHRONIZE:
return CodeReviewTrigger.ON_NEW_COMMIT
case _:
raise ValueError(f"Unsupported pull request action: {action}")
| if action not in WHITELISTED_ACTIONS: | ||
| return | ||
|
|
||
| if pull_request.get("draft") is True: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Later I'm guessing we're going to want to start tracking this metric later too to inform whether we should allow our feature on drafts or not
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not certain if this is necessary since we check the actions and there's a draft action.
| """Helper to set up code review test context.""" | ||
| self.organization.update_option("sentry:enable_pr_review_test_generation", True) | ||
| features_to_enable = self.CODE_REVIEW_FEATURES if features is None else features | ||
| options_to_set = dict(self.OPTIONS_TO_SET) | (options or {}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is nice
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you!
Support sending GitHub `pull_request` events to Seer instead of Overwatch.
0f4e7aa to
71fb508
Compare

This change adds support for forwarding GitHub pull_request events to Seer instead of Overwatch.